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    Telephony Routing over IP (TRIP) Attribute for Resource Priority

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   This document defines a new attribute for the Telephony Routing over
   IP (TRIP) protocol.  The attribute associates protocols/services in
   the PSTN offering authorized prioritization during call setup that
   are reachable through a TRIP gateway.  Current examples of
   preferential service in the Public Switched Telephone Network (PSTN)
   are Government Emergency Telecommunications Service (GETS) in the
   U.S. and Government Telephone Preference Scheme (GTPS) in the U.K.
   The proposed attribute for TRIP is based on the NameSpace.Value tuple
   defined for the SIP Resource-Priority field.

1.  Introduction

   An IP telephony gateway allows nodes on an IP-based network to
   communicate with other entities on the circuit switched telephone
   network.  The Telephony Routing over IP (TRIP) protocol [rfc3219]
   provides a way for nodes on the IP network to locate a suitable
   gateway through the use of Location Servers.  TRIP is a policy-
   driven, inter-administrative domain protocol for advertising the
   reachability, negotiating the capabilities, and specifying the
   attributes of these gateways.

   The TRIP protocol is modeled after BGP-4 [rfc4271] and uses path-
   vector advertisements distributed in a hop-by-hop manner (resembling
   a Bellman-Ford routing algorithm) via Location Servers.  These
   Location Servers are grouped in administrative clusters known as
   Internet Telephony Administrative Domains (ITADs).  A more extensive
   framework discussion on TRIP can be found in [rfc2871].
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   This document defines a new attribute that has been registered with
   IANA.  The purpose of this new attribute, and the rationale behind
   its specification, is explained in the following sections.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [rfc2119].

2.  Emergency Telecommunications Service

   Emergency Telecommunications Service is a broad term that refers to
   the services provided by systems used to support emergency
   communications.  One example of these systems is the U.S. Government
   Emergency Telecommunications Service (GETS).  This system currently
   operates over the U.S. Public Switched Telephone Network (PSTN) as a
   pay-per-use system by authorized personnel.  It uses the T1.631-1993
   ANSI standard [ANSI] to signal the presence of the National Security
   / Emergency Preparedness (NS/EP) codepoint in an ISDN User Part
   (ISUP) Initial Address Message (IAM) for Signaling System No. 7
   (SS7).  A key aspect of GETS is that a signaling standard in the U.S.
   PSTN is used to convey the activation/request of the GETS service.

   From a protocol perspective, other examples of priority (and which
   can be argued as emergency/disaster related) standards are the
   H.460.4 ITU [itu460] standard on Call Priority designation for H.323
   calls, and the I.255.3 [itu255] ITU standard on Multi-Level
   Precedence and Preemption Service.  The latter has been integrated
   into private telephony systems like AUTOVON.  In both cases,
   signaling codepoints exist to distinguish telephony calls by
   authenticated and prioritized end-user from the normal end-user.  The
   form of this distinction varies and is outside the scope of this
   document.  [rfc3689] and [rfc3690] provide additional information on
   ETS and its requirements.

3.  SIP Resource-Priority Effort

   The initial discussions in the IEPREP working group list, along with
   the presentation at the Adelaide IETF [ADEL00], led to strawman
   requirements to augment SIP to have the ability to prioritize call
   signaling.  This effort was then advanced formally in the SIPPING
   working group so that SIP would be able to prioritize access to
   circuit-switched networks, end systems, and proxy resources for
   emergency preparedness communication [rfc3487].

   The requirements in [rfc3487] produced the corresponding document
   [rfc4412] in the SIP working group, which defines a new header for
   SIP called Resource-Priority.  This new header, which is optional, is
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   divided into two parts: a NameSpace and a Value.  The NameSpace part
   uniquely identifies a group of one or more priorities.  The Value
   part identifies one of a set of priorities used for a SIP message.

3.1.  Benefits

   There are three basic benefits derived from the addition of the
   Resource Priority header in SIP.  The first is an ability to signal
   the priority within a SIP message to other entities in an IP network.
   The caveat is that some entities may not recognize/support the
   priority or namespace, but at least the ability to signal the
   priority with respect to resources has been specified in the SIP
   protocol.

   The second benefit is that telephony-related protocol/codepoints from
   other standards can have a corresponding mapping to SIP NameSpace and
   Value tokens in the Resource-Priority header.  Hence, the current
   NS/EP codepoint in ANSI standard T1.631-1993 could have a
   corresponding NameSpace.Value token set for the IETF standards body.
   And as a result, this mapping would facilitate the transparent
   bridging of signals (i.e., codepoints) between standards defined by
   various organizations -- be they private or public.

   The third benefit of the Resource-Priority header, and its definition
   of alphanumeric tokens, is that it is highly versatile.  The
   NameSpace allows for a wide set of priorities to be defined and
   updated, if the need arises, by simply defining a new NameSpace
   token.  Hence, there is no reliance on a single set of priorities
   applied for all cases.

3.2  Issue

   Having defined a means of signaling priority through gateways, the
   follow-on question arises of how does one determine which gateways
   support a given NameSpace.  The dissemination of this type of
   information is within the scope of TRIP.  However, the current
   specification of TRIP does not include a component that advertises
   associations of gateways with specific NameSpaces.  To address this
   omission, the following section defines a new TRIP attribute that
   associates one or more NameSpaces with a gateway.
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4.  New Attribute: ResourcePriority

   This section provides details on the syntax and semantics of the
   ResourcePriority TRIP attribute.  Its presentation reflects the form
   of existing attributes presented in Section 5 of [rfc3219].

   Attribute Flags are set to the following:

      Conditional Mandatory: False
      Required Flags: Not Well-Known, Independent Transitive
      Potential Flags: None
      TRIP Type Code: 12

   There are no dependencies on other attributes, thus Conditional
   Mandatory is set to "False".

   Since the Resource-Priority field in SIP, with its corresponding
   NameSpace token, is optional, the ResourcePriority attribute in TRIP
   is also optional.  Hence, it is set to "Not Well-Known".

   The Independent Transitive condition indicates that the attribute is
   to be forwarded amongst all ITADs.  The Location Server that does not
   recognize the attribute sets the Partial flag as well.

4.1.  Syntax of ResourcePriority

   The ResourcePriority attribute contains one or more NameSpace token
   identifiers.  An initial set of identifiers is defined in [rfc4412],
   with subsequent identifiers to be found in the IANA registry.  The
   syntax of the ResourcePriority attribute is copied from the
   "namespace" token syntax from [rfc4412], which in turn imported
   "alphanum" from [rfc3261], and is an alphanumeric value as shown
   below:

   namespace = 1*( alphanum / "-" / "!" / "%" / "*" / "_" / "+"
                   / "`" / "'" / "~" )

   Note that an augmented version of Backus-Naur Form is found in
   [rfc4234].

   Since NameSpaces are arbitrary in length, each tuple consists of a
   Length value with a NameSpace value as shown in the figure below.
   There is no padding between tuples.
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    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +---------------+---------------+--------------+----------------+
   |        NameSpace Length       |   NameSpace Value (variable)  |
   +---------------+---------------+--------------+----------------+

   It is important to note that the priority (i.e., "r-priority" token
   syntax) from [rfc4412] is NOT used in the ResourcePriority attribute.
   This is because the objective of the attribute is to advertise the
   NameSpace associated with a gateway and not the individual priorities
   within that NameSpace.

4.2  Additional TRIP Considerations

   Section 5.12 of TRIP lists a number of considerations that should be
   addressed when defining new attributes.  The first three
   considerations (use of the attribute, its flags, and syntax) have
   been discussed above in this section.  The final three considerations
   are the following.

4.2.1.  Route Origination

   The ResourcePriority attribute is not well-known.  If a route has a
   ResourcePriority attribute associated with it, the Location Server
   (LS) MUST include that attribute in the advertisement it originates.

4.2.2.  Route Aggregation

   Routes with differing ResourcePriority token values MUST NOT be
   aggregated.  Routes with the same token values in the
   ResourcePriority attribute MAY be aggregated and the same
   ResourcePriority attribute attached to the aggregated object.

4.2.3.  Route Dissemination and Attribute Scope

   An LS MUST include the ResourcePriority attribute when communicating
   with peer LSs within its own domain.

   If received from a peer LS in another domain, an LS MUST propagate
   the ResourcePriority attribute to other LSs within its domain.

   An LS MAY add the ResourcePriority attribute when propagating routing
   objects to an LS in another domain.  The inclusion of the
   ResourcePriority attribute is a matter of local administrative
   policy.
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5.  Security Considerations

   The document defines a new attribute for the TRIP protocol and has no
   direct security considerations applied to it.  However, the security
   considerations for TRIP and its messages remain the same and are
   articulated in Section 14 of [rfc3219].

6.  IANA Considerations

   As described in Section 4 above, one new "TRIP attribute" has been
   defined.  Its name and code value are the following:

      Code                    Attribute Name
      ----                   ----------------
       12                    ResourcePriority

   These assignments are recorded in the following registry:
      http://www.iana.org/assignments/trip-parameters
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